1. Field of the Invention
Embodiments of the present invention generally relate to authentication of users of computing devices. More particularly, the present invention relates to authentication using one-time passwords (OTPs) where multiple OTPs (or OTP Tokens) are issued to a user from a single service provider.
2. Description of the Related Art
Recently, the rapid rise of network threats has exposed the inadequacies of static passwords as the primary form of authentication over the Internet. As an alternative, OTPs are emerging as a popular form of authentication for securing network access.
OTPs avoid a number of shortcomings that are associated with traditional (static) passwords. Most importantly, the OTPs are not vulnerable to replay attacks. On the downside, OTPs cannot be memorized by human beings. There are different ways to make the user aware of the next OTP to use. Some systems use special electronic tokens (e.g., a key fob) that the user carries and that generates OTPs and displays them to the user on a small display. Other systems consist of software that runs on the user's mobile telephone, computer, PDA, or other computing device that generates and displays the OTPs to the user. Still other systems generate OTPs on the server-side and send the OTPs to the requesting user using an out-of-band channel, such as SMS messaging. An application accesses the OTPs received out-of-band and presents or displays them to the user. Finally, in some systems, OTPs are printed on paper that the user is required to carry with him or her. Regardless of the approach used, the term “token” as used herein indicates the user-side component that generates, displays, and/or presents the OTPs to the user, irrespective of whether the component is implemented in hardware, software, or a combination of hardware and software.
OTP technology relies on coordination or synchronization between the device generating the OTP for the user and the server that is verifying the OTP. Typically, in cases where the OTP is being generated at the user side (e.g., on or using the token) and the server side independently, the coordination consists of a secret and a current counter value. The counter value is what changes each time a new OTP is generated. The OTP is generated in a cryptographically secure manner using both the secret and the counter value.
The passwords themselves may be generated in one of two ways: either as time-synchronized passwords or counter-synchronized passwords. Time-synchronized OTPs use the current time to derive the counter and are subject to problems caused by clock skew. That is, if the authentication server and the user token don't keep the same time, then the expected OTP value won't be produced and the user authentication will fail. So, this technique requires a reliable time source at the user end which is difficult in the case of software implementations running on hand-held devices or computers that are not time-synced accurately. A counter-synchronized OTP solution synchronizes a counter between the electronic computing device and the server. Each time an OTP is generated, the token increments the internal counter value by one. On the server, for each successful authentication, the server also increments its counter value by one. In this way, the token's and the server's counter values stay synchronized in lock step and will typically generate the same one-time password. Counter based tokens may get out of sync if the token is asked to generate several OTPs that are never actually used in authentication attempts. Then the token's counter value is increased while the server's counter value is not increased, leading to a synchronization problem. When a synchronization problem occurs, a token-generated OTP may fail an authentication attempt because the server doesn't recognize the token-generated OTP.
Regardless of how passwords are generated, OTPs today are deficient in that they are typically suitable only for use in scenarios where an issuer (such as a bank) issues a single OTP to a user, and the user may then use that single OTP to access goods or services provided by that issuer. In some cases, a user may have multiple OTPs, but each OTP is only operable to access goods or services provided by one service provider. None of the known techniques for generating OTPs consider situations where an issuer desires to issue multiple OTPs to a single user for accessing goods or services from a single service provider, nor do they consider the problems that arise in such situations or potential solutions for addressing such problems.